Summit 2015 is less than three weeks away.

Looks like I'll be attending. Any other FocalPointers?

One of my plans at Summit, is to thank in person, all those who have helped me through this forum, if they are attending.

If anyone is not attending, and would like me to ask an 'Ask Gerry' question, feel free to reply or send me a PM. I have a few I'll be submitting.

I've installed the 'Summit 2015' app; if anyone else has, we could contact each other there that way.

Safe travels.

This message has been edited. Last edited by: <Kathryn Henning>,

I'll be there ...

Ya mo be there.

Even though I'm going, I'm not sure if I will be making it to the Q/A session. Try asking him why they made the dumb decision to disable the ability to access the HTML. Or why you can't add your own .js files into your Content folders. So annoying.

CoolGuy,

I've actually asked a few people in IBI why the decision was made to move away from allowing people access to the HTML. From what I understand, I think it comes down from Gerry himself. I think the idea is that they were getting to many support calls to help people with their HTML. I think people were adjusting the xml and IBI's attributes, causing them to support people breaking their HTML pages. So I think within IBI the thought has come through that the GUI is the best approach for most users. This also explains the push to use Info assist more and the push within App Studio to get more and more people building reports as well with the GUI. I think they believe that be "simplifying" the tools they can increase their user base.

To a certain extent I understand and agree with the push to improve and use the GUI more. But only to the point of simplifying things for the end user. One of IBI's greatest strengths is a developers ability to fully customize their reports. The more you take away a developers ability to code, the harder it becomes for a developer to use the advanced techniques like MacGyver and loops. Not to mention that the HTML composer doesn't respect div tags, which makes it so incredibly hard to build a Web page appropriately, let alone import a page that your graphics department has created for your use.

Now all of this is hearsay and should be taken with a grain of salt. But this decision wasn't made to help the developers and programmers who understand Web technologies, it was made for the users who don't, at the expense of the developers and progammers.

Oh and david, i'll be at summit. Feel free to pm me to connect on the summit app.

I won't be at Summit but IMO, App Studio and Dev Studio should be for developers not end users. I've been working where I am at now for 20 year and in all that time I have 1 end user that I would even consider giving App or Dev Studio too. Our database has over 800 tables and ease of getting data out has never been a consideration of design. The primary focus has always been ease of getting data in. Giving end users development tools like App/Dev Studio would be a complete disaster.

Eric.Woerle and others,

Thanks for your insights on IBI's decision to handicap their actual user base (developers) over the developers' user base (end users). I really think they should have thought through that one a bit more. What they should have done was retain the openness of access to all code, but place the tool-generated code within a collapsed and commented section within the developer's/end user's code warning to not alter or mess with it. This is how Visual Studio does it with C# through #region tags. This way we (the devs) can still manipulate and view all the code, but still let the end users (non-devs) have what they need, but with a warning that hopefully they will be intelligent enough to heed.

I concur that even the most "user friendly" tools aren't much use if the users don't undestandt the structure of the data.

At the behest of our users we instituted a trial of InfoAssist and I gave it to the two most tech savvy members of staff to try it out.

I gave them an afternoon of instruction and then left them to it. Result: They never used it - not once!

It's interesting that we now have an entire forum devoted to InfoAssist with much of the discussion centered around how to do things that are only readily available in Dev Studio.

quote:

the GUI is the best approach for most users

Ha ha!

I may be the only one, but I believe IBI's mantra is "there are no developers only users... there are no developers only users... there are no developers only users... there are no developers only users...".

Thanks everyone.

I think we can now try to reach a consensus on the question to be asked.

Does this sound like a reasonable consensus question?:

quote:

Will Information Builders continue to support the professional developer, as it has in the past? This question is being asked in the context of what seems like a recent emphasis on supporting the end-user, at the exclusion of the developer. A specific concern, behind this question, is that the appreciation for the elegance, power and ease of coding directly in the WebFOCUS language, by developers, might no longer be shared with folks at IB.

This has been a question on my mind as well, and I am looking forward to asking it.

at this rate, will there be either?

quote:

at this rate, will there be either?

David,

That sounds great! Look forward to hearing back with what they say! Appreciate your help!

David,

I found your final sentence:

quote:

A specific concern, behind this question, is that the appreciation for the elegance, power and ease of coding directly in the WebFOCUS language, by developers, might no longer be shared with folks at IB.

to be a bit convoluted.

Could you perhaps reword it something like this:?

My specific concern, shared by many of my colleagues on Focal Point, is that the the elegance, power, and ease of coding directly in the WebFOCUS language, by developers, is no longer appreciated, or understood, by the folks at IB.

Thank you George! Agreed. Done.

quote:

Will Information Builders continue to support the professional developer, as it has in the past? This question is being asked in the context of what seems like a recent emphasis on supporting the end-user, at the exclusion of the developer. My specific concern, shared by many of my colleagues on Focal Point, is that the elegance, power, and ease of coding directly in the WebFOCUS language, by developers, is no longer appreciated, or understood, by the folks at IB.

I'll pay $20 to watch a You Tube video of this question being asked and of the response from IBI.

Francis, me too. I'm completely amazed by the lack of knowledge displayed by some people on the IBI helpdesk when it comes to FOCUS language questions.

Very funny Francis!! Are you expecting, as I am, that they will talk all around the subject without actually getting to the point?

As I read this I'm saddened to think that developers have zero say in this. Sounds like paying penance to King Saul at the loss of economic livelihood.

We've moved from an end-user application ( brio / hyperion ) to a developer-environment because, frankly, those end-user haven't got a clue what they're doing.

They had way to much freedom enabling them to make stupid mistakes without much effort. And delibarte data-manipulation ( or data-torturing ) in their favor.

This was totally stopped since we provide parameterized reports.

The number of questions and remarks from CEO and CFO about the differences in reports from various departments has been reduced to 0.


Why the H311 is IBI so eager move business intellingence from specialists to the consumers?

Even when the tool is very user-friendly and easy to learn. That's not the issue. It's the lack of business knowledge and general knowledge how to deal with numbers that kills the BI.



...I believe the US expression is : My two cents ;-)

What IBI is doing to the developer by taking away functionality is like giving a thirsty person a drink but telling them to hold out their hands in a cupping shape and they'll pour the drink therein because they don't provide cups anymore, spilling quite a bit in the process. Then the still thirsty individual eventually goes elsewhere.

Exactly, Dave. My users simply don't understand the data, and forget how to interpret output even on reports specifically requested by them six months earlier.

And even though they only get parameterized or ReportCaster reports they still come back to me frequently saying "Number X on one report doesn't equal number Y on another". I have to point out things such as that the date parameters are different (e.g. a calendar month vs a 4-week period) or that they are mixing dollars and kilos, and so on. There is simply no way they can produce their own reports and get something useful.

I spent nearly all of two months earlier this year on a targets vs. sales project. The sales manager asked me to provide last year's sales for each sales rep in a specific spreadsheet format with a whole lot of columns that I knew to be useless/confusing/wrong and some that were necessary, but not included.

I suggested a different approach and sent him data and graphs that would be much more useful. He told me to shut up and produce exactly what he asked for, so I did. The sales reps and managers subsequently filled in the spreadsheets - modifying them in the process, so no two were the same format or had the same product code for a given product - and sent them back to me so I could match this year's sales against the targets. Result: Absolute garbage, but two salesmen have lost their jobs, partly because their numbers don't stack up, despite my efforts to massage the corrupted data into something meaningful.

To suggest that these folks, who can't even construct a spreadsheet, should be creating their own reports, is preposterous.

Dave / George

I have to disagree with you two on the grounds that a healthy BI environment will support both the utilization of well written Paramaterized Reports AND a healthy end user base with access to tools like InfoAssist or a custom designed Guided Adhoc (Possibly Both).

Because of this belief, I whole heartedly support IBI's desire to improve on the End User experience. Remember the developers are really a small percentage of the people actually using the system.

BUT the developer is core to promoting the product and providing the real Impressive reporting. KPI's and things that drive company initiatives should be coming from your developers (For example Georges Example with the sales numbers to compare against last year). But the Sales district manager should be able to create the reports that are meaningful to HIM for managing his sales people. Even be able to share those with his people for them to manage themselves.

There is plenty of space for both Developer Centric and End User Centric tools in this place. My aggravation comes when one replaces the other (either way).

Don't forget that the pace at which end users will need new data will far outweight your capablities to develop all of it. So while you are building your systems to quickly get information in (which by the way is important for a transactional system), remember that the strength of a reporting system centers around the ability to get information out quickly, in the most easily understood way for the End User.

I'll see you there...

David, I have one more question I would like IBI to answer.

Many years ago, I took the Top Gun class. Everything you wanted to know about FOCUS internals but were afraid to ask. Without a doubt, and there is not even a close second, the most valuable IBI class I ever took. Why is it no longer offered? They covered TABLE, TABLEF, MODIFY, COMBINE, Dialogue Manager, etc. I realize that some of the class is not really valid anymore for most of us (like CRTFORM in MODIFY), but it was a fantastic class. I learned more in that one class that I have in all FUSE (yes I go back that far), SUMMITS, and other IBI classes combined.

quote:

Originally posted by jgelona (posted Sat May 16 2015 10:50):
... IMO, App Studio and Dev Studio should be for developers not end users.

But, if the end users don't have the tools, like App Studio and Dev Studio , what would they use to develop their own reports?

quote:

Originally posted by Francis Mariani (May 19 13:50):
[QUOTE]I may be the only one, but I believe IBI's mantra is "there are no developers only users... there are no developers only users... there are no developers only users... there are no developers only users...".

So, IB, who does all the real development?

quote:

Originally posted by jgelona (May 21 09:00):
I'm completely amazed by the lack of knowledge displayed by some people on the IBI helpdesk when it comes to FOCUS language questions.

I agree. However, IB's goal, as lofty as it may be, is to be able to do "everything" in the GUIs. In the meantime, which is likely to be forever, we, the Real Developers, do need access to the actual code to get WebFOCUS to do those things that the GUI has yet to conquer.

quote:

George Patton (May 22 10:32):
My users simply don't understand the data

quote:

To suggest that these folks, who can't even construct a spreadsheet, should be creating their own reports, is preposterous.

But, can THEY do it in WebFOCUS if they can't handle a spreadsheet?

I think that it's more about the data. We, or our DBA's need to provide source with the emphasis of normalizing it for reporting, with all the underlying JOINs, etc. Then of course, training the users to understand that data from that perspective.
Just my 2 cents...